閱讀程式

程式設計程式基礎

Pieta 2022-05-28 02:01:05 ‧ 14003 瀏覽

分享至

前言

Clean Code，老聖經一本，是一本如何撰寫大家都能輕易看懂的Code，當中最重要的是閱讀程式，因此特別開一篇文章聊一聊閱讀程式，主要是未來希望能拿來當教育訓練用的文件。
以下會用一個題目當範例，當然這也是我常用的面試題，並在後續留下常見的解，請各位體驗一下，何謂閱讀程式。

5/28 09:30對於許多內容增加了語意修正，解釋。

題目

這是會議過後，PM給的客戶需求，需求為：
完成以下閏年的規則的Function，無論語言。

公元年分非4的倍數，為平年。
公元年分為4的倍數但非100的倍數，為閏年。
公元年分為100的倍數但非400的倍數，為平年。
公元年分為400的倍數為閏年。

答案

以下會列出常見的幾種答案，並且在下面註解用中文閱讀的狀況。

答案1

function isLeap(year) {
  return ((year % 4) === 0 && (year % 100) !== 0) || (year % 400) === 0;
}

公元年為4的倍數且公元年非100的倍數，或公元年為400的倍數，為閏年。

答案2

function isLeap(year) {
  if (year % 4 === 0 && year % 100 !== 0) return true;
  else if (year % 400 === 0) return true;
  else return false;
}

公元年為4的倍數且公元年非100的倍數，為閏年。
公元年為400的倍數，為閏年。
剩下則為平年。

答案3

function isLeap(year) {
  if (year % 4 === 0) {
    if (year % 100 === 0) {
      if (year % 400 === 0) {
        return true;
      } else {
        return false;
      }
    } else {
      return true;
  } else {
    return false;
  }
}

如下圖：

答案4

function isLeap(year) {
  if (year % 400 === 0) return true;
  else if (year % 100 === 0) return false;
  else if (year % 4 === 0) return true;
  else return false;
}

公元年為400的倍數，為閏年。
其他公元年為100的倍數，為平年。
其他公元年為4的倍數，為閏年。
其他公元年，為平年。

答案5

function isLeap(year) {
  if (year % 4 !== 0) return false;
  if (year % 4 === 0 && year % 100 !== 0) return true;
  if (year % 100 === 0 && year % 400 !== 0) return false;
  if (year % 400 === 0) return true;
}

公元年分非4的倍數，為平年。
公元年分為4的倍數但非100的倍數，為閏年。
公元年分為100的倍數但非400的倍數，為平年。
公元年分為400的倍數為閏年。

答案6

function isLeap(year) {
  if (year % 4 !== 0) return false;
  else if (year % 100 !== 0) return true;
  else if (year % 400 !== 0) return false;
  return true;
}

公元年分非4的倍數，為平年。
其他公元年為非100的倍數，為閏年。
其他公元年為非400的倍數，為平年。
其他公元年，為閏年。

分析

個人會選擇答案5或答案6，原因是，今天PM、客戶，在會議後，提出了非常明確的需求，我不建議去做轉換（換句話說），這樣的行為在我的工作經驗中，是具有高風險的，非常常看到，難解的邏輯bug都是放在這種狀況內，如果一開始就選擇答案5、答案6去撰寫程式，一來你會code會完成的非常快，因為只做翻譯；二來不可能失誤，會失誤的話，PM、客戶剛開始就是錯的，如果真的不滿意這樣的需求，也應該透過會議討論修正。

效能爭議

對於效能爭議，我認為這個爭議是非常小的，原因如下：

無論如何撰寫這題目永遠會是三層判斷。
若編譯上面的所有答案，編譯結果都會非常接近。
在討論演算法時，通常是討論倍數、指數的效能問題，而非討論一行兩行的效能優化。
根據我的工作經驗，更多時候在討論效能問題前，更常見的是程式過度術語化、複雜化，造成商業上損失的bug，更為常見，個人是提倡清楚的Code、降低Bug，而非效能擺在第一位。
確實有個缺點，在類似JS的環境中，你會將整個檔案傳送到前端運行，語句的長短，會影響到傳輸的效能，但個人認為比起bug這樣的缺點值得的。